Forum PHP.pl

Witam, chciałbym się dowiedzieć czy mając włączone magic_quotes na serwerze i zapytanie sformułowane w taki sposób: "SELECT * FROM tabela WHERE id='$id'" jest możliwość wstrzyknięcia niechcianego zapytania (brak jakiejkolwiek filtracji danych)? Jeżeli tak (a zapewne tak jest) to w jaki sposób atakujący może tego dokonać?

Pozdrawiam

magic_quotes to najgorsze co może być.. Wyłącz to i napisz swoją walidację a nie jakieś cuda (IMG:style_emoticons/default/smile.gif) Nie jestem pewien ale chyba da się bez problemów włamać nawet z magic_ - Jeśli się mylę, poprawcie (IMG:style_emoticons/default/smile.gif)

No właśnie niby mówi się, że magic_quotes jest ble i fuj, ale szukałem sposobów na jego obejście no i jakoś nie znalazłem (być może źle po prostu szukałem), więc jak na razie jedyne zagrożenie które dostrzegam w jego użytkowaniu to po prostu problemy kiedy swoją aplikacje będziemy musieli przenieś na serwer na którym magic_quotes jest wyłączone.

Pozdrawiam, mam nadzieję że ktoś będzie potrafił mnie uświadomić dlaczego magic_quotes to zło

Albo gdy będziesz płakać, gdy w końcu z PHP to wyrzucą (bo obiło mi się o uszy, że są takie plany).


http://en.wikipedia.org/wiki/Magic_quotes

Mam nadzieję, że ludzie kiedyś nauczą się korzystać z wyszukiwarek i tego, co mają pod nosem.

Chciałbym dowiedzieć się czy używanie PDO i metod prepare(), execute() jest bezpieczne z punktu widzenia SQL Injection? Czy mimo to warto używać add/stripslashes

Przeczytałem cały temat i zastanawia mnie dlaczego nie pojawiło się filtrowanie $_GET, $_POST etc. przy pomocy array_map funkcją htmlspecialchars, trim i mysql_real_escape_string. Takie filtrowanie jest bardzo skuteczne i nawet jeśli zapytanie do bazy jest źle skonstruowane i nie filtrowane, takie jak poniżej to potencjalny hacker nic nie zdziała.

[PHP] pobierz, plaintext 
$sql = mysql_query(SELECT * FROM news WHERE id=$_GET['id']);
[PHP] pobierz, plaintext 

Oczywiście dla pewności należy przy tym pamiętać o poprawnych typach kolumn w SQL i mimo wszystko rzutowaniu na (int), sprawdzaniu długości (substr) i dla szerszej ochrony wykrywanie przedwcześnie zalogowanych kont, które szukają dziur.

Poza tematem via msg, to chętnie wymienię się informacją jak ominąć filtr mysql_real_escape_string za ominięcie is_numeric - wiem że się da.

O ile w normalnych warunkach wszystko jest ok to jeżeli sprzedajemy aplikację chinczykowi to może być już problem. Zróbcie sobie bazę z kodowaniem i sprawdzcie taki kodzik:

[PHP] pobierz, plaintext 
<?php
date_default_timezone_set('Europe/Warsaw');
if(!empty($_GET))
{
  $db = new mysqli('localhost', 'uzytkownik', 'haslo', 'nazwa_bazy');
  $db -> set_charset('big5'); // kodowanie bazy big5!!
 
  $login = addslashes($_GET['login']);
  $password = addslashes($_GET['password']);
 
  $result = $db->query('SELECT * FROM users WHERE login="'.$login.'" AND password=MD5("'.$password.'")');
 
  if($row = $result->fetch_assoc())
  {
    print_r($row);
  }
}
?>
[PHP] pobierz, plaintext 

Teraz w adresie wystarczy podać np.



Efekt:

[SQL] pobierz, plaintext 
SELECT * FROM users WHERE login="admin?" OR 1=1 --" AND password=MD5("qwerty")
[SQL] pobierz, plaintext 

Sytuacja wygląda analogicznie z mysql_real_escape_string() - w koncu to prawie identyczna funkcja jak addslashes

@fr33d0m: jeślichcesz, to mogę wysłać Ci przez msg listę kodowań i wytłumaczenie dlaczego jest tak a nie inaczej.

Pozdro

Ten post edytował SHiP 13.10.2011, 12:15:47

Nie zagłębiam się aż tak w inne kodowanie niż europejskie bo jest mi to nie potrzebne. Aby zapobiec i zrozumieć SQL Injection/Insertion trzeba zawężyć krąg kodowań do naszych rodzimych, które są często używane bo nowym userom przez przykład kodowania z Chin można tylko w głowie zamieszać.



---edit:
@SHiP
Wierzę na słowo, że przy zabezpieczeniu kodowań wszystkich znaków świata trzeba mieć głowę na karku. (IMG:style_emoticons/default/smile.gif)
Potrafię pominąć mysql_real_escape_string. A swoją drogą to z matematyki miałem 5 więc doskonale wiem dlaczego jest tak, jak jest w kodowaniu Chińskim. (IMG:style_emoticons/default/wink.gif)

Ten post edytował fr33d0m 13.10.2011, 12:40:22

Chodziło mi o przedstawienie przykładu, który pokaże, że używanie metod typu addshasles() to pomyłka. Problem chińskiego kodowania nie jest trywialny. Pisząc dużą aplikację(np. taki wordpress) należy wziąć pod uwagę, że będą z niej korzystać Azjaci z kodowaniami bogatymi w różne fajne znaczki.

PS: co do Twojej propozycji. Umiesz złamać mysql_real_escape_string() czy is_numeric() ? Bo nie wiem co, za co chcesz się wymieniać

A to akurat nieprawda, bo mysql_real_escape_string() zwraca uwagę na kodowanie

A tu też nie do końca jest pięknie z tym kodowaniem mysql_real_escape_string(); (IMG:style_emoticons/default/biggrin.gif)

http://forum.php.pl/index.php?s=&showt...st&p=911748

No akurat jest, bo na MySQL5 (chyba 5.0.23, nie szukałem) to już nie działa. A jak ktoś ma zamiar korzystać z MySQL4 to nie ma po co się babrać z omijaniem filtrów bo jest kilka innych exploitów na tak starą wersję pozwalającą na zdalne wykonanie kodu.

Ten post edytował pyro 5.11.2011, 20:49:06

Jest prosty sposób na szybkie wyczyszczenie danych w razie włączonych magic_quotes (w wypadku gdy nie możemy go wyłączyć).

[PHP] pobierz, plaintext 
<?php
      if (get_magic_quotes_gpc()) {
        function stripslashes_gpc(&$value)
        {
          $value = stripslashes($value);
        }
        array_walk_recursive($_GET, 'stripslashes_gpc');
        array_walk_recursive($_POST, 'stripslashes_gpc');
        array_walk_recursive($_COOKIE, 'stripslashes_gpc');
        array_walk_recursive($_REQUEST, 'stripslashes_gpc');
      }
?>
[PHP] pobierz, plaintext 

Nie chcę tutaj polemizować na ten temat bo nie mogę znaleźć info. na ten temat. Masz jakieś linki ?

Linki do czego? Mam 3 wersje MySQL5+ i na żadnym z nich nie działa to co opisał tamten użytkownik na blogu.

Temt SQL Injection/Insertion nigdy mnie nie dotyczyl ale jesli nad tym sie zastanowic to porzadna kontrola tresci zalatwia sprawe w 70% a jak to komus to nie wystarcza to tak jak na ssl kazda strona ma swoj super tajny klucz to niech i akcja na bazie bedzie miala swoj super tajny klucz. Przed akcja z baza jakies autorskie fikumiku na tresci a podczas odczytywania mikufiku i pozamiatane. Wtedy nawet przegladanie phpMyAdmin nikomu nic nie da co prawda bedze mogl w ramach akcji protestu skasowac cala baze danych ale od czego jest backup.

takie pytanie - dane filtrować mysql_real_escape_string przed dodaniem do bazy czy zaraz po odebrania formularza? chodzi oto, że między tymi akcjami mam jeszcze sprawdzanie czy coś zostało podane, weryfikacja np meila i inne weryfikacje. stąd to pytanie.

bo ocenie robię to po odebraniu formularza:

[PHP] pobierz, plaintext 
$title= isset($_POST['title']) ? $sql->html($_POST['title']) : '';
 
if(empty($title))
	$form['info'] .= 'Wpisz tytuł podstrony'."\n";
 
//zapytanie dodajace wpis do bazy
[PHP] pobierz, plaintext 

Przeczytaj do czego służy mysql_real_escape_string a poznasz odpowiedź na swoje pytanie.

Użycie PDO w następujący sposób

[PHP] pobierz, plaintext 
$pdo = new PDO("mysql:host=localhost;dbanme=xxx", "root", "");
$zap = $pdo->prepare("INSERT INTO `uzytkownicy` (`login`, `haslo`, `email`) VALUES(:login, :haslo, :email)");
$zap->bindValue(":login", $_POST['login'], PDO::PARAM_STR);
$zap->bindValue(":haslo", $_POST['haslo'], PDO::PARAM_STR);
$zap->bindValue(":email", $_POST['email'], PDO::PARAM_STR);
$zap->execute();
$zap->closeCursor();
[PHP] pobierz, plaintext 

jest wystarczającym zabezpieczeniem?

Tak.